feat(accounts): serve harness credentials from the vault, and mint keys as a principal - #27

Summary

Two things that make dcrypt useful to something other than a human at the UI.

1. dcrypt as a credential provider. @agentic-kit/harness doesn't do auth — it defines the contract and makes the host supply it. VaultCredentials is that host, reading the unlocked vault instead of a plaintext account.json:

class VaultCredentials {
  accountBearer(): Promise<string | null>          // the signed-in account's token
  dataToken(databaseId): Promise<DataTokenResult>  // { token, origin: 'vault' }
}

The interesting part is what it won't do. It refuses rather than guesses: null when no account is signed in, when several are and none was named, when the token has expired, and when zero — or two — keys claim the database. Nothing is cached, so every call re-reads the vault and locking cuts every consumer off at once. A data token is served even while its account is signed out, because an API key is its own credential, not a derivative of a session.

Keys learn which database they are for, as ordinary (non-concealed) metadata:

createApiKey(accountItemId, { name: 'ci', databaseId })
assignKeyToDatabase(keyItemId, databaseId)  // touches only the tag, never the secret

2. Principals. A Constructive principal is a scoped sub-identity — what a key or an agent actually acts as — owned by a human and able only to narrow them: isReadOnly, a per-scope allowedMask AND-ed with the owner's permissions during the SPRT cascade, and bypassStepUp so CI isn't blocked on someone's phone. No override row for a scope means it simply inherits the owner there, which the CLI says out loud rather than rendering an empty list.

const principalId = await accounts.createPrincipal(itemId, { name: 'ci-deploy', orgId, isReadOnly: true });
await accounts.createApiKey(itemId, { name: 'ci', principalId, orgId });  // → createOrgApiKey

So "ci-deploy-key" becomes an identity with its own mask instead of a copy of your access. createApiKey routes to createOrgApiKey when an orgId is given; both carry principalId. Principals are read from the server on demand and deliberately not mirrored into the vault — a stale local copy of someone's permissions is worse than none. Creating and deleting one goes through the same withStepUp hold-and-replay as every other sensitive call.

CLI:

dcrypt account token [email] [--database <id>]
dcrypt account key create ci --principal <id> --org <id> --database <id>
dcrypt account key assign ci db-1
dcrypt account principal list|create|delete

Tests

packages/accounts covers the refusals specifically — ambiguous accounts, ambiguous databases, expired tokens, a data token surviving sign-out, and that assignKeyToDatabase leaves the concealed secret untouched — plus principal creation, step-up on creation, deletion, and refusing to reach the server when signed out. Repo lint, build, test and desktop typecheck are green.

Not in this PR: the desktop UI for principals, and the IPC that would expose the provider to another process.

Link to Devin session: https://app.devin.ai/sessions/04636534e07048089ffb6b78142e12cd
Requested by: @pyramation